1. Field of the Invention
The present invention relates to the field of data processing. More specifically, embodiments of the present invention relate to a Java loading system and method.
2. Related Art
Electronic systems and circuits have made a significant contribution towards the advancement of modern society and are utilized in a number of applications to achieve advantageous results. Numerous electronic technologies such as digital computers, calculators, audio devices, video equipment, and telephone systems have facilitated increased productivity and reduced costs in analyzing and communicating data in most areas of business, science, education and entertainment. These advantageous results are often realized by computer systems implementing a virtual machine such as a Java virtual machine (JVM). A Java virtual machine is a process that runs on a host system executing binaries associated with class files. The JVM implements an abstraction referred to as a class loader that locates bytes associated with a class name and produces a translated representation of a Java class instance in a memory. However, traditional Java virtual machine loading architectures can be relatively complex and involve a number of restrictive implementation requirements that often result in limited implementation flexibility and typically consume significant system resources.
Java is an object oriented language in which classes are “specifications” (expressed as a piece of program code) that define common parameters or properties of objects included in the class. The Java applications or programs include classes. Some environments (e.g., Java two enterprise edition (J2EE)) typically permit concurrent execution of separate applications, where each application can involve multiple modules with Java classes packaged in various forms. The traditional rules governing isolation between these various components generally require the use of multiple “class loaders”, each of which can hold only a single version of any given class. The classes that form a given version of a technology solution (e.g. an XML parser, such as Xerces) are generally packaged and distributed in one or more “code-source” root locations from which the classloader searches for classes. Code sources are generally anything that can be asked for a class and return it. For example, codes-sources can be defined to represent physical storage of binary class files, java sources that are compiled, or classes generated on the fly. A class loader in Java normally contains one or more “code-sources” (e.g., “Jar” or “zip” files) from which to load classes. A class loader uses each code source, along with a fully qualified class name (e.g., which includes a class package name) to define a location to search for classes.
Class loaders are typically arranged in a “tree” structure, with each loader having a single parent. When a class load event occurs, a loader is selected (called the “initiating” loader), and the standard search algorithm searches up the parent chain before searching the current (“initiating”) loader. The first class matching the class name is returned. When a “child” contains the same class as one of its parents, the parent's version is traditionally selected effectively “masking” the child's copy. Traditional attempts at addressing situations in which related applications (e.g., applications in the same container) require the same version of a given technology (e.g. Xerces 2.5.0) typically deploy that technology in a class loader that is a parent to all application loaders (i.e. global), thus enabling sharing of those classes. However, when two applications in the same container require different versions of the same technology (e.g. Xerces 2.5.0 or 2.6.0), the conventional solutions tend to break down (e.g., due to search order masking).
Conventional approaches to addressing situations in which two applications in the same container require different versions of the same technology typically involve removing the globally deployed classes and bundling the appropriate jars within each application, thus isolating them from other applications in the container. Another application deployed to the container that requires the same classes traditionally has to bundle its own copy, and therefore the classes are not shared. In addition, if two applications bundle and use the same technology, objects created from the classes of that technology can not typically be shared between the applications. The duplication can also be a source of complex errors. For example, if two different class loaders load the same class, there are two different class instances (each with is own separate static data) and attempts to cast an object from one to another usually produce a ClassCastException, resulting in troubleshooting situations that are hard to understand and difficult to diagnose.
Aside from the difficulty of making conventional duplication changes for addressing situations in which two applications in the same container require different versions of the same technology, the duplication can involve other detrimental results. For example, the duplication can cause significant resource consumption, often resulting in increased operation costs. Furthermore, J2EE containers are often required to provide an implementation of certain technologies (e.g. an XML parser or a JDBC driver) for use by all applications. Some containers attempt to deploy these technologies globally but applications that require different versions are typically unusable on that type of container configuration.